System, Method and Computer Program Product for Tamper Protection in a Data Storage System

ABSTRACT

Systems, methods and computer software utilized in the implementation of tamper protection, where unique information associated with data storage tapes and with particular revisions of these tapes is stored on the storage medium itself and on a memory of the tape cartridge, so that the data can be compared to determine whether unauthorized modifications have been made to the tapes. One embodiment is a system which includes an archive node appliance coupled between a set of hosts and a tape media library. The archive node appliance presents files stored on a tape of a media library as a directory. The archive node appliance maintains tamper protection data on the tape and on an auxiliary memory on the cartridge of the tape, and determines from this data whether the tape has been altered by an authorized system.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims a benefit of priorityunder 35 U.S.C. 120 of the filing date of U.S. patent application Ser.No. 14/271,207, filed May 6, 2014, entitled “SYSTEM, METHOD AND COMPUTERPROGRAM PRODUCT FOR TAMPER PROTECTION IN A DATA STORAGE SYSTEM,” whichis a continuation of, and claims a benefit of priority from U.S. patentapplication Ser. No. 13/480,781, filed May 25, 2012, entitled “SYSTEM,METHOD AND COMPUTER PROGRAM PRODUCT FOR TAMPER PROTECTION IN A DATASTORAGE SYSTEM,” issued as U.S. Pat. No. 8,756,687, which are fullyincorporated by reference herein for all purposes.

TECHNICAL FIELD

This disclosure relates to the field of data storage. More particularly,this disclosure relates to systems, methods and computer software whichare utilized in the implementation of tamper protection, where uniqueinformation associated with data storage tapes, and with particularrevisions of these tapes, is stored on the storage medium itself and ona memory of the tape cartridge, so that the data can be compared todetermine whether unauthorized modifications have been made to thetapes.

BACKGROUND

Businesses, governmental organizations and other entities areincreasingly saving large volumes of data necessary for dailyoperations. This data represents a significant asset for these entities.Consequently, data loss, whether accidental or caused by maliciousactivity, can be costly in terms of wasted manpower, loss of goodwillfrom customers, loss of time and potential legal liability. To ensureproper protection of data for business and legal purposes (e.g., toensure quick recovery of data in the event of a disaster, to comply withdocument retention requirements, etc.), these entities often back updata to a physical media, such as magnetic tapes or optical disks on aregular basis.

Traditional backup systems placed an application server, backup server,source device, destination device and a local area network (“LAN”) inthe data path of backup operations. Under these systems, the LANs werebecoming overburdened by the amount of data being copied. Often, thebackup window (the period in which data unavailable for normaloperations in order to permit backup) was too short to achieve acomplete backup of data. Accordingly, many entities implemented StorageArea Networks (“SAN”) to relieve the burden of mass data storage andbackup from the LAN, freeing the LAN for more immediate data storage andmanipulation operations. In SANs data from multiple machines on anetwork may be backed up to a remote media library. Centralized databackup allows storage problems to be identified at one location and hasthe advantage of increased efficiency.

One example of a media library commonly used in enterprise backupsystems is a magnetic tape library. In a typical magnetic tape library,tapes are contained in cartridges and the tape library contains multiplecartridge slots in which tape cartridges can be stored. The tapecartridges are physically moved between cartridge slots and tape drivesby a robot. The robot is controlled by access commands received from thehost devices on the network. When specific data is required, the hostdevice determines which cartridge slot contains the tape cartridge thatholds the desired data. The host device then transmits a move-elementcommand to the robot and the robot moves the tape cartridge.

Recently, the Linear or Long Term File System (LTFS) FormatSpecification by IBM and Ultrium (hereby fully incorporated by referencein its entirety for all purposes) has been developed, which defines afile system for LTO-5 tapes, LTO-6 tapes and may be extended to othertapes using an eXtensible Markup Language (XML) schema architecture.This file system support allows the use of an LTFS-formatted tape as ifit were a file system. Files and directories may appear in a directorylisting, files may be dragged and dropped from tape, data may beaccessed at the file level, etc.

Consequently, while it previously was necessary to make use of a backupapplication to write and read tapes, the introduction of LTFS hassimplified the storing and retrieval of files on tape by reducing suchoperations to a copy. Furthermore, any operating system that includesLTFS support can mount an LTFS formatted tape and read and write thefiles thereon.

However, LTFS does not provide an adequate mechanism for ensuring thatthe data stored on LTFS tapes has not been modified in an unauthorizedmanner, such as by removing a tape from a library, modifying the tapeusing an unauthorized system, and then returning the tape to thelibrary.

SUMMARY

Embodiments described herein include systems, methods and computersoftware which are utilized in the implementation of tamper protection,where unique information associated with data storage tapes and withparticular revisions of these tapes is stored on the storage mediumitself and on a memory of the tape cartridge, so that the data can becompared to determine whether unauthorized modifications have been madeto the tapes.

One embodiment described herein is a system for providing tamperprotection of data storage tapes, where the system includes a medialibrary and an archive node appliance. The media library has a set ofdrives and a set of media. The archive node appliance is coupled to themedia library and to a set of hosts. The archive node appliance has adata store and a processor which executes a set of program instructions.The instructions cause the processor to: (i) maintain, for a file, a setof first file system metadata according to a first type of file system;(ii) present, as located at a first location and according to the set offirst file system metadata, the file using a first file system of thefirst type of file system; (iii) maintain the file at a second locationon a tape of a media library using a second file system of a second typeof file system, wherein the second location mirrors the first location;(iv) maintain at least a portion of the set of first file systemmetadata on the tape in addition to a set of second file system metadatastored by the second file system; and (v) determine, based at least inpart upon data stored on the tape, whether the tape has been altered byan authorized system.

In one embodiment, the program instructions cause a first set of tamperdetection data (also referred to herein as tamper protection data) to beread from the tape, and cause a second set of tamper detection data tobe read from a MAM (“medium auxiliary memory” or “media access memory”)of the tape cartridge. The two sets of tamper detection data are thencompared to determine whether the data match (in which case the tape hasnot been altered by an authorized system), or do not match (in whichcase the tape has been altered by an authorized system). The tamperdetection data may include an index generation value associated withmodification of the tape, a universally unique identifier (UUID)associated with the tape, verification data generated using the indexgeneration value, the UUID, or both, a checksum associated with ametadata file on the tape, or combinations of these values. The programinstructions may also cause the processor to store the tamper detectiondata on the tape and MAM when the files stored on the tape are updated.

An alternative embodiment comprises a computer program product in whicha non-transitory computer readable medium has a set of instructionsstored thereon. The instructions are executable by a processor to: (i)maintain, for a file, a set of first file system metadata according to afirst type of file system; (ii) present, as located at a first locationand according to the set of first file system metadata, the file using afirst file system of the first type of file system; (iii) maintain thefile at a second location on a tape of a media library using a secondfile system of a second type of file system, wherein the second locationmirrors the first location; (iv) maintain at least a portion of the setof first file system metadata on the tape in addition to a set of secondfile system metadata stored by the second file system; and (v)determine, based at least in part upon data stored on the tape, whetherthe tape has been altered by an authorized system. The instructions maybe configured to read the tamper protection data from the tape and theMAM of the tape cartridge, and may also be configured to write thetamper protection data to the tape and MAM. The tamper protection datamay include an index generation value associated with modification ofthe tape, a universally unique identifier (UUID) associated with thetape, verification data generated using the index generation value, theUUID, or both, a checksum associated with a metadata file on the tape,or combinations of these values.

Another alternative embodiment is a method that includes the steps: (i)maintaining, for a file, a set of first file system metadata accordingto a first type of file system; (ii) presenting, as located at a firstlocation and according to the set of first file system metadata, thefile using a first file system of the first type of file system; (iii)maintaining the file at a second location on a tape of a media libraryusing a second file system of a second type of file system, wherein thesecond location mirrors the first location; (iv) maintaining at least aportion of the set of first file system metadata on the tape in additionto a set of second file system metadata stored by the second filesystem; and (v) determining, based at least in part upon data stored onthe tape, whether the tape has been altered by an authorized system. Themethod may include reading the tamper protection data from the tape andfrom the MAM of the tape cartridge, and may also include writing thetamper protection data to the tape and MAM. The tamper detection datamay include an index generation value associated with modification ofthe tape, a universally unique identifier (UUID) associated with thetape, verification data generated using the index generation value, theUUID, or both, a checksum associated with a metadata file on the tape,or combinations of these values.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings accompanying and forming part of this specification areincluded to depict certain aspects of the invention. A clearerimpression of the invention, and of the components and operation ofsystems provided with the invention, will become more readily apparentby referring to the exemplary, and therefore nonlimiting, embodimentsillustrated in the drawings, wherein identical reference numeralsdesignate the same components. Note that the features illustrated in thedrawings are not necessarily drawn to scale.

FIG. 1 is a diagrammatic representation of one embodiment of systemcomprising an Archive Node Appliance.

FIG. 2 is a diagrammatic representation of one embodiment of an ArchiveNode Appliance.

FIG. 3 is a diagrammatic representation of one embodiment of an ArchiveNode Appliance.

FIG. 4 is a diagrammatic representation of one embodiment of an ArchiveNode Appliance.

FIGS. 5A-5D are diagrammatic representations of one embodiment of aschema.

FIG. 6 is a flow chart illustrating one embodiment of a method forstoring a file.

FIG. 7 is a flow chart illustrating one embodiment of a method forstoring metadata of one file system on a tape using another file system.

FIG. 8 is a flow chart illustrating one embodiment of data stored on atape.

FIG. 9 is a flow chart illustrating another embodiment of storingmetadata of one file system on a tape using another file system.

DETAILED DESCRIPTION

The invention and the various features and advantageous details thereofare explained more fully with reference to the nonlimiting embodimentsthat are illustrated in the accompanying drawings and detailed in thefollowing description. Descriptions of well-known starting materials,processing techniques, components and equipment are omitted so as not tounnecessarily obscure the invention in detail. It should be understood,however, that the detailed description and the specific examples, whileindicating preferred embodiments of the invention, are given by way ofillustration only and not by way of limitation. Various substitutions,modifications, additions and/or rearrangements within the spirit and/orscope of the underlying inventive concept will become apparent to thoseskilled in the art from this disclosure. Embodiments discussed hereincan be implemented in suitable computer-executable instructions that mayreside on a computer readable medium (e.g., a hard disk drive, flashdrive or other memory), hardware circuitry or the like, or anycombination.

Before discussing specific embodiments, embodiments of a hardwarearchitecture for implementing certain embodiments is described herein.One embodiment can include one or more computers communicatively coupledto a network. As is known to those skilled in the art, the computer caninclude a central processing unit (“CPU”), at least one read-only memory(“ROM”), at least one random access memory (“RAM”), at least one harddrive (“HD”), and one or more input/output (“I/O”) device(s). The I/Odevices can include a keyboard, monitor, printer, electronic pointingdevice (such as a mouse, trackball, stylus, etc.) or the like. Invarious embodiments, the computer has access to at least one database.

ROM, RAM, and HD are computer memories for storing data andcomputer-executable instructions executable by the CPU. Within thisdisclosure, the term “computer-readable medium” is not limited to ROM,RAM, and HD and can include any type of data storage medium that can beread by a processor. In some embodiments, a computer-readable medium mayrefer to a data cartridge, a data backup magnetic tape, a floppydiskette, a flash memory drive, an optical data storage drive, a CD-ROM,ROM, RAM, HD, or the like.

At least portions of the functionalities or processes described hereincan be implemented in suitable computer-executable instructions. Thecomputer-executable instructions may be stored as software codecomponents or modules on one or more computer readable media (such asnon-volatile memories, volatile memories, DASD arrays, magnetic tapes,floppy diskettes, hard drives, optical storage devices, etc. or anyother appropriate computer-readable medium or storage device). In oneembodiment, the computer-executable instructions may include lines ofcompiled C++, Java, HTML, or any other programming or scripting code.

Additionally, the functions of the disclosed embodiments may beimplemented on one computer or shared/distributed among two or morecomputers in or across a network. Communications between computersimplementing embodiments can be accomplished using any electronic,optical, radio frequency signals, or other suitable methods and tools ofcommunication in compliance with known network protocols.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, article, orapparatus. Further, unless expressly stated to the contrary, “or” refersto an inclusive or and not to an exclusive or. For example, a conditionA or B is satisfied by any one of the following: A is true (or present)and B is false (or not present), A is false (or not present) and B istrue (or present), and both A and B are true (or present).

Additionally, any examples or illustrations given herein are not to beregarded in any way as restrictions on, limits to, or expressdefinitions of, any term or terms with which they are utilized. Instead,these examples or illustrations are to be regarded as being describedwith respect to one particular embodiment and as illustrative only.Those of ordinary skill in the art will appreciate that any term orterms with which these examples or illustrations are utilized willencompass other embodiments which may or may not be given therewith orelsewhere in the specification and all such embodiments are intended tobe included within the scope of that term or terms. Language designatingsuch nonlimiting examples and illustrations include, but is not limitedto: “for example,” “for instance,” “e.g.,” “in one embodiment.”

It will be recalled from the above discussion that in many instances itmay be desired to provide a file system utilizing media libraries. Tothat end, attention is now directed to systems and methods forimplementing a file system utilizing a tape library. In particular,embodiments may present a network based file system to one or more hostdevices. These host devices may utilize the network based file system toorganize, store, read or perform other operations in association withfiles. These files may be managed in conjunction with a tape library.Specifically, commands in a network file system protocol may bereceived. These commands may be associated with operations to beperformed on files, including operations associated with theorganization, storage or retrieval of those files. Library controlfunctionality that allows tapes in the tape library to be tracked andtapes to be moved into and out of drives and storage slots is utilizedto manage the tape library.

In certain embodiments, LTFS (including Library LTFS) may be employed inconjunction with the tape library such that the tapes in the tapelibrary may be formatted using LTFS. Accordingly, operations withrespect to the files on the tapes in the tape library may be performedusing LTFS. A mapping may be maintained between the files visiblethrough the networked based file system presented to the host devicesand the corresponding location of those files on an LTFS tape in thetape library. It should be noted here that while embodiments asdiscussed include a tape library having tapes formatted according toLTFS, other types of media libraries that utilize media of the same ordifferent type where the media may be formatted according to the same oranother type of file system may be employed in other embodiments.

To increase performance, embodiments of such a system may include a datastore, which may be on a storage medium that is relatively faster forrandom accesses such as a disk. Files that are stored by the hostdevices using the networked based file system may initially be stored onthe disk. These files are subsequently migrated to tapes in the tapelibrary. Once a file has been migrated all, or a portion of, that filemay be deleted from the disk. When a file is subsequently accessed itcan be determined if the file is on the disk or stored on tape. The filecan then be accessed from the disk, a tape or a combination of the two.File operations performed through the network file system can occur onfiles in the data store, rather than directly on the file on tape.

In some cases, it may be desirable to move a tape from one system toanother and have the files on tape presented out in a similar manner bythe second system as was done by the first system. Accordingly,embodiments provided herein can utilize self-describing tapes that allowthe files read from the tape to be presented out similarly by multiplesystems. The tape can store metadata of both the file system used tostore files on the tape (e.g., LTFS) and the file system used to presentout the files read from the tape to provide for consistent filedescriptions between systems.

FIG. 1 is a diagrammatic representation of a system in which a medialibrary is managed to present a network based file system to a pluralityof hosts (i.e., host devices). Archive Node Appliance 115 can compriseone or more communications interfaces 150, 151 (e.g., fibre channelinterface, Ethernet port or any other type of communication interfaceknown in the art) to connect Archive Node Appliance 115 to network 120and network 122. In this embodiment, hosts 110, 111, 112 and 113 arecoupled to an Archive Node Appliance 115 via network 120. Network 120can comprise the Internet, a LAN, a WAN, a SAN, a wireless network, orany other communications link, network or protocol known in the art. Forexample, network may comprise an Ethernet based network employingTCP/IP.

Archive Node Appliance 115 is coupled to media library 130 via network122 (Archive Node Appliance 115 and media library 130 may becollectively referred to as an Archive Node or a Networked Attached TapeArchive (NATA)). Network 122 can comprise the Internet, a LAN, a WAN, aSAN, a wireless network, or any other communications link, network orprotocol known in the art. For example, network 122 may comprise a fibrechannel network (such as a fibre channel SAN) or a SCSI bus, such as aSerial Attached SCSI (SAS) bus. While Archive Node Appliance 115 hasbeen depicted as a standalone device in this embodiment, it should beunderstood that Archive Node Appliance 115 can be implemented in avariety manners and in a variety of architectures. For example, whenimplemented in a SAN, the Archive Node Appliance may be part of arouter, part of a media library or at any other location in acommunication path between hosts and a media library.

Media library 130 may comprise a tape library or another media libraryknown in the art such as optical jukeboxes. A tape library, as would beunderstood by one of ordinary skill in the art, typically consists ofone or more tape drives that can read/write data from/to magnetic tape(contained within cartridges also referred to herein as tapes or tapecartridges), eject tape cartridges and perform other operations. Aseries of slots stores the tape cartridges when they are not in a driveand a robot moves the magnetic tape cartridges between the drives andslots.

As an example, media library 130 can comprise drives 131-133, robot 134and slots 135 (individually slots 135 a-j). It should be noted that amedia library that employs a single robot or multiple robots in anexpandable or modular configuration, but presents itself as a singlemedia library to a network, or any other configuration of one or moremedia libraries, either physical or virtual, that can present itself asa single media library can be considered a single media library for thepurposes of this application. It will also be noted that though theembodiment depicts only a single media library, other embodiments may becoupled to, and utilize, multiple media libraries.

Archive Node Appliance 115 comprises a computer processor 152 and acomputer readable memory 154 (e.g., RAM, ROM, magnetic disk, opticaldisk and/or any other computer readable memory known in the art) thatcan store computer instructions 155 that are executable by processor152. Computer instructions 155 can be implemented as hardware, software,firmware, some combination or in any other suitable manner as would beunderstood by those of ordinary skill in the art.

In operation, computer instructions 155 can be executable such thatArchive Node Appliance 115 can present a network based file system(i.e., a file system accessible over a network) to hosts 110, 111, 112,113, allowing these hosts to organize, store or retrieve files orperform other operations associated with a file system. Operations thatcan be performed using such network based files systems are understoodby those of skill in the art. This network based file system may be forexample, a Network File System (NFS) based file system, a CommonInternet File System (CIFS) based file system, a File Transfer Protocol(FTP) based file system, a Secure Copy Protocol (SCP) based file system,a Representational State Transfer (REST) based file system, or a filesystem based on any another type of protocol which allows a file systemto be accessed over a network.

Computer instructions 155 may thus be executable to implement operationsassociated with the presented network based file system in conjunctionwith media library 130. More specifically, in one embodiment, drives131, 132, 133 may be LTO-5, LTO-6 compliant drives and tapes in medialibrary 130 may be formatted according to LTFS (as disclosed in theLinear Tape File System Format Specification Version 2.0, or otherversion by IBM, hereby incorporated by reference in its entirety). Inother embodiments the drives may be compliant with other types of tapesand the tapes may be formatted according to other tape file systems.Computer instructions 155 may be executable to store files receivedthrough the networked based file system on the LTFS tapes in the medialibrary 130 and maintain mapping information between the files visiblethrough the network based file system and the location of those files inthe media library.

The files visible through the network based file system can be filesstored at an intermediate location (e.g., a disk based data store ormemory). When a file visible through the network based file system isaccessed, computer instructions 155 can be executed to provide access tothe file from the intermediate location. File operations can thus occuron the file at the intermediate location rather than directly on thefile on the tape.

In some cases, the file may not reside entirely in the intermediatestorage when the file is accessed. Therefore, the computer instructions155 can also be executable to determine the location of the accessedfile in the media library 130 using the mapping information, locate andload the correct tape into a drive, and use LTFS to mount the LTFS filesystem on the tape and access the file to, for example, read theremainder of the file into the intermediate storage.

To increase performance, in some embodiments, it may be desired to storefiles on computer readable memory 154 when they are initially received,and migrate these files to the media library 130 at a later point.Computer instructions 155 may therefore be executable to store filesstored by hosts using the network based file system to the computerreadable memory 154. At some later point, the computer executableinstructions 155 may be executable to migrate the file from the computerreadable memory 154 to the media library 130. In this case, computerexecutable instructions 155 are executable to maintain mappinginformation between the files visible through the network based filesystem and the location of those files on the computer readable memory154 or the media library 130.

The use of LTFS in conjunction with the media library 130 can afford anumber of advantages when employed by an Archive Node Appliance 115 toimplement a networked based file system. One important advantage is thatthe file system structure presented through the file system may besubstantially mirrored on the tapes of the media library 130.Accordingly, if there is a failure of the Archive Node Appliance 115 ormedia library 130, the files on the tapes of the media library 130 maybe easily located, as they are stored according to a structure that issubstantially identical to that defined by the users at the hosts usingthe network based file system.

Furthermore, the use of LTFS means that tapes on which files of thenetwork based file system are stored may be mounted and the file systemon these tapes accessed, using any computing device which supports LTFS.As LTFS is commonly provided in many of today's operating systems, thesetapes (and files stored thereon) may be easily accessed, allowing filesto be restored or otherwise manipulated without requiring specializedsoftware.

To put a finer point on some of the advantages offered by embodimentsdisclosed herein, the functionality and performance of a network basedfile system may be achieved while simultaneously achieving the benefitsof storage on a medium typically used for backup without the need forany type of specific backup application. The use of an Archive NodeAppliance may abstract the media library to implement a network basedfile system and hide the corresponding complexity entailed by the use ofsuch a media library. By using a computer readable memory which isrelatively faster for random accesses such as a disk in conjunction withthe media library to provide the network based file system the ArchiveNode Appliance may provide the speed customarily associated with anetwork based file system by masking the latency of the use of the medialibrary. Simultaneously, the use of such a media library provides thebenefit of having files automatically stored on a storage mediatypically used for backup without specific action by users or the use ofa backup application.

Furthermore, the use of LTFS in conjunction with the media libraryallows the file system created by users using the network based filesystem to be mirrored on the storage media. Thus, when restoring filesfrom the storage media of the media library in the event of a failure,no specialized structural knowledge is required. The files on thestorage media are in the locations where they were placed by the usersin conjunction with the network based file system. Moreover, since LTFSis commonly supported data on the storage media may be easily accessedwithout the need for specialized software such as a backup application.

It may be helpful here to illustrate architectures for certainembodiments of an Archive Node. FIG. 2 depicts one embodiment of anarchitecture for an Archive Node that may be used in instances whererelatively lower capacity is desired. Here, the Archive Node Appliance200 may comprise one or more Gigabit Ethernet ports 210. These GigabitEthernet ports 210 may be dedicated to providing a user interface or fora systems management interface such as the Intelligent ManagementPlatform Interface (IPMI). The Archive Node Appliance 200 may alsocomprise one or more Ethernet ports 220 for data connections. TheseEthernet ports may be 10BASE-T, 100BASE-TX, 1000BASE-T, 10GBASE-LR,10GBASE-LW, 10GBASE-LRM, 10GBASE-ZR, 10GBASE-LX4, 10BASE-CX4, etc. ormay be of a mixture of types. In operation these Ethernet ports 220 maybe coupled to hosts, such that a network based file system may beprovided by the Archive Node Appliance 200 and hosts may interface withthe Archive Node Appliance 200 using these Ethernet ports 220 to utilizethe network based file system, for example, by storing or retrievingfiles using the network based file system. The network based file systemmay be implemented using a file system implemented in association withuser space such as the File system in User space (FUSE) file system;using a kernel-based file system such as Ext2, Ext3, Ext4 Next3, etc.;or almost any other type of file system desired.

Archive Node Appliance 200 also includes a data store 230. Data store230 may be a computer readable memory used to store computer executableinstruction, files stored using the network based file system or otherdata utilized by Archive Node Appliance 200, as will be elaborated on inmore detail subsequently. To ensure some degree of redundancy or faulttolerance, data store 230 may implemented as Redundant Array ofIndependent Disks (RAID) storage having around 5 TB-8 TB of availablestorage. Archive Node Appliance 200 also comprises a SAS port 250through which the Archive Node Appliance 200 is coupled to media library260 via a SAS bus. Media library 260 may be an IBM TS3100 tape libraryhaving one or more LTO-5 compliant drives 262 and capable of holding 24tape cartridges or an IBM TS3200 tape library having one or more LTO-5compliant drives 262 capable of holding 48 tape cartridges. In otherembodiments, the media library may include LTO-6 compliant drives orother types of drives.

While it should be noted that Archive Node Appliance 200 may beimplemented in substantially in any form factor desired, in oneembodiment Archive Node Appliance may be based on a rack-mount storageformat and may, for example, be contained in a chassis of a 1U, 2U or 3Uform factor with the data store residing internally to the chassis.

Moving on, FIG. 3 depicts one embodiment of an architecture for anArchive Node that may be used in instances where relatively greaterstorage capacity is required, such as in, for example, large datainstallations or a cloud storage provider. In this embodiment, theArchive Node Appliance 300 may comprise one or more Gigabit Ethernetports 310. These Gigabit Ethernet ports 310 may be dedicated toproviding a user interface or for a systems management interface. TheArchive Node Appliance 300 may also comprise one or more Ethernet ports320 for data connections. These Ethernet ports may be 10BASE-T,100BASE-TX, 1000BASE-T, 10GBASE-LR, 10GBASE-LW, 10GBASE-LRM, 10GBASE-ZR,10GBASE-LX4, 10BASE-CX4, etc. or may be of a mixture of types. Inoperation these Ethernet ports 320 may be coupled to hosts, such that anetwork based file system may be provided by the Archive Node Appliance300 and hosts may interface with the Archive Node Appliance 300 usingthese Ethernet ports 320 to utilize the network based file system, forexample, by storing or retrieving files using the network based filesystem. As noted above, the network based file system may be implementedusing a file system implemented in association with user space such asthe File system in User space (FUSE) file system; using a kernel-basedfile system such as Ext2, Ext3, Ext4 Next3, etc.; or almost any othertype of file system desired. Archive Node Appliance 300 also includes adata store 334.

Data store 334 may be a computer readable memory used to store computerexecutable instructions, files stored using the network based filesystem or other data utilized by Archive Node Appliance 300. To ensureredundancy or fault tolerance, data store may comprise a mirrored systemdisk 332 comprising the computer executable instruction and other datautilized by the Archive Node Appliance 300 during operation andRedundant Array of Independent Disks (RAID) storage 334 coupled to theArchive Node Appliance 300 through SAS port 336. The RAID storage may beused to store files associated with the network based file system andmay have around 9 TB-150 TB of available storage. Archive Node Appliance300 also comprises fibre channel ports 350 through which the ArchiveNode Appliance 300 is coupled to media library 360 via a fibre channelswitch 362. These fibre channel ports 350 may be, for example, 16, 8, 4or 2 GB fibre channel ports. Media library 360 may be an IBM TS3500 tapelibrary having one or more LTO-5 compliant drives 364 and capable ofholding around 20,000 tapes, a media library having one or more LTO-6compliant drives or a media library supporting other types of tapes thatcan be formatted according to a tape file system.

Again, while it should be noted that Archive Node Appliance 300 may beimplemented in substantially in any form factor desired, in oneembodiment Archive Node Appliance 300 may be based on a rack-mountstorage format and may for example, be contained in a chassis of a 1U,2U or 3U form factor with the data store residing internally to thechassis or portions of the data store, such as the RAID storage residingexternal to the chassis.

Turning now to FIG. 4, one embodiment of a functional architecture foran Archive Node is depicted. Archive Node Appliance 400 may provide anoperator interface 402 through which the Archive Node Appliance 400 maybe configured. Such an operator interface 402 may be provided, forexample, using a network based interface such as a set of web pages orthe like. Archive Node Appliance 400 is coupled to tape library 410,comprising a set of LTO-5, LTO-6 or other tape compliant drives some ofwhich may be LTFS (or other tape file system) formatted tapes. In oneembodiment, each tape in tape library 410 may be used to store data thatis compressed, data that is encrypted, data that is both compressed andencrypted or data that is neither compressed nor encrypted.

Archive Node Appliance 400 comprises Filesystem in Userspace (FUSE)module 412 that may presents a file system to a local operating system.A network file system interface module 413 provides access to all or aportion of the FUSE file system as one or more shared volumes (e.g., asa hierarchical file system with directories, etc.) that can be accessedusing an interface that operates according to network file systemprotocol 414 such as NFS, CIFS, FTP, REST etc. Data associated with theshared volumes is stored on one or more partitions of data store 418 (acomputer readable memory), where the structure of the partitions of thedata store 418 may, or may not, correspond to the structure of theshared volumes or to the structure of the file system presented by FUSEmodule 412.

Directory operations module 420 is configured to process any directoryoperations that are received by FUSE module 412. I/O operations module422 is configured to process any input or output operations involvedwith the reading or the storing of files associated with the file systempresented by the FUSE module 412. These operations include, for example,the writing of files to the data store 418, the reading of files fromthe data store 418, the deletion of files from the data store 418, thereading of files from a tape in the tape library 410 or other operationsassociated with the data store 418 or tape library 410.

These I/O operations may involve the use of library control module 434,LTFS module 424, LTFS management module 432 and index 436. The locationof each tape within the tape library 410 may be maintained in index 436(e.g., in which slot or drive each tape is located, in which library thetape is located if multiple tape libraries are in use, etc.).Additionally, in one embodiment, what type of data is stored on eachtape (encrypted, compressed, neither encrypted nor compressed, etc.) mayalso be maintained.

Library control module 434 is configured to control the movement of thetapes in the tape library 410, including ejecting the tapes from thedrives of the tape library 410, and the movement of tapes to and fromslots of the tape library 410 and in and out of drives of the tapelibrary using the robot. LTFS management module 432 is configured tomount or unmount the LTFS file system on a particular tape in a drive ofthe tape library 410. LTFS module 424 is configured to perform LTFSoperations with respect to an LTFS mounted file system.

Library control module 434, LTFS module 424, LTFS management module 432and index 436 may also be utilized by file migration module 426. Filemigration module 426 is configured to move files from data store 418 totape library 410 based on policies 428. File mapping module 438maintains map 442 which correlates a file visible through the FUSE filesystem to its corresponding location in the tape library 410.Specifically, a mapping between the location (for example the path) andname of the file with respect to the FUSE file system, the name andlocation of that file in the data store 418 and the name and location ofthat file on one or more tapes in the tape library 410 may be maintainedin map 442.

Policies 428 may, or may not be, user configured and may be associatedwith storage of the files or the migration of files from the data store418 to tapes in the tape library 410. Such policies may specify, forexample, how long to wait before migrating a file (referred to herein asa migration timeout period), whether the files are to be replicated whenmigrated (e.g., stored in conjunction with multiple Archive Nodes aswill be elaborated on in more detail), how many copies of the file tokeep, where the multiple copies are to be kept on different tapes,whether the file is to be encrypted or compressed, etc. The policies 428may be defined with respect to the directories presented with respect tothe FUSE module 412 such that those policies may be defined with respectto all files within that directory. Policy management module 430 allowsthese policies to be managed (e.g., created, updated, defined, deleted,modified, etc.) by a user or otherwise. Policies can be defined at anylevel of the directory structure provided by FUSE module 412. Because adirectory presented by FUSE module 412 may be presented as a sharedvolume by network file system interface module 413, a policy thatapplies to the directory may also apply to the share.

In operation then, Archive Node Appliance 400 may present a networkbased file system accessible through an interface, where the filesassociated with the network based file system may be stored on the tapelibrary 410 according to a file system structure that substantiallymirrors the file system structure of the presented network based filesystem. In one embodiment, mirroring the file system structure of thepresented network based file system means that at least a portion of thepath of the location of the file as it is stored on the tape library 410may be substantially similar to the path of the location of the file asit is presented through the file system.

More specifically, users at host devices coupled to the Archive NodeAppliance 400 may perform directory operations and store or read filesusing an interface for the network based file system provided by theArchive Node Appliance 400. In accordance with these user initiatedoperations, commands in the network file system protocol 414 employed bythe interface may be received at the Archive Node Appliance 400 andimplemented by FUSE module 412 with respect to the partitions of datastore 418. If the command is associated with a directory operation itmay be processed by directory operations module 420. If the command isfor the storing of a file, the I/O operations module 422 may write thisfile to a location in the data store 418. Map 442 may be updated tocomprise a mapping between the location and name of the file withrespect to the FUSE file system and the name and location of that filein the data store 418.

In one embodiment, the file is stored in the data store 418 according tothe one or more policies that apply to that file. For example, if apolicy that applies to the file specifies that the file should becompressed the file may be compressed before the file is stored in thedata store 418. Similarly, if an applicable policy specifies that thefile is to be encrypted the file may be encrypted before it is stored inthe data store 418. In certain embodiments, a self-encrypting disk, fulldisk encryption or a RAID controller which performs encryption may beutilized in conjunction with data store 418, such that all files storedin the data store 418 may be encrypted by the disk or controller whenthe file is stored to the data store 418. In such cases, all filesstored to the data store 418 may be encrypted when stored to data store418 and decrypted when read from data store 418.

Based on one or more of the policies 428, at some later point a file maybe migrated to the tape library 410. As policies 428 may be definedbased on a location associated with the presented file system, policiesassociated with the location (e.g., directory, share, etc.) where thefile is stored may be determined from policies 428 and the determinedpolicies applied to migrate the file.

As the file may be received over a network, errors may occur during thetransmission of the file or the storage of the file to the data store.To account for network errors or the like, in one embodiment, a timeperiod referred to as the migration timeout period is utilized. Morespecifically, when a file is first stored to the data store an amount oftime equal to the migration timeout period may be allowed to elapsebefore the file is migrated. As discussed above, such a migrationtimeout period may be implemented as a policy. Thus, for example, apolicy defining such a migration timeout period may be associated with ashare or directory as visible through the network based file systemimplemented by the Archive Node Appliance.

In any event, once a file is selected for migration, the one or morepolicies 428 associated with that file may be utilized to migrate thefile accordingly (e.g., encrypted, compressed, neither encrypted norcompressed, whether multiple copies of the file are to be maintained, ifthe file is to be replicated, etc.).

An appropriate tape on which to store the file may be determined andlocated using the index 436. If the appropriate tape is not currently ina drive of the tape library, library control module 434 may be utilizedto load the appropriate tape into a drive of the tape library 410. Morespecifically, in most cases when an LTFS tape is formatted it isspecified whether the data on that tape is to be compressed or not.Thus, the selection of an appropriate tape may include selecting a tapethat is formatted according to a policy specified for the file beingmigrated (e.g., a tape formatted to hold compressed data may be selectedif a policy specifies the file is to be compressed, etc.), selecting atape that has a location associated with a location where the file is tobe stored (e.g., a directory in the path of the location where the fileis to be stored, etc.), etc. The selection of an appropriate tape mayalso involve other considerations not expressly enumerated.

The file system on the appropriate tape may be mounted using LTFSmanagement module 432. File migration module 426 may use LTFS module 424to copy the file from data store 418 to the appropriate tape at alocation on the tape which corresponds to the location of the file aspresented through the file system to the host devices coupled to theArchive Node Appliance. After the file is copied to the tape, all, or aportion of, the file may be deleted off of the data store. Accordingly,the migration may entail the creation of one or more directories on themounted LTFS file system on the tape, where these directories may mirrorthe directories in the path where the file is stored that are visible toa user at a host device using the network based file system presented bythe Archive Node Appliance 400. Additionally, when the file is copied tothe mounted LTFS file system on the appropriate tape, actions may betaken to implement policies applicable to the file.

For example, if a policy that applies to the file specifies that thefile should be compressed, the media drive can be instructed to compressthe file. In one embodiment, the use of LTFS may simplify thiscompression. Specifically, if a file is to be compressed the selectionof an appropriate tape formatted to store compressed data may indicateto the LTFS module 424 that data to be stored on the tape is to becompressed. The LTFS module 424 may configure the drive holding thattape to compress data such that when the file is stored to the tapeusing LTFS module 424 it is compressed as it is stored.

Similarly, if an applicable policy specifies that the file is to beencrypted, the drive can be instructed to encrypt the file. Encryptionof the file being stored may be accomplished by the tape drive in whichthe appropriate tape is located. Specifically, before mounting the LTFSfile system on the appropriate tape one or more commands (for example,SCSI or other types of commands that may or may not include keyinformation to be utilized) may be sent to the drive to cause it to useencryption. The LTFS file system can then be mounted on the tape. LTFScan then be used to store the file on the tape while the tape drivehandles the encryption of the data transparently to LTFS.

Other embodiments may accomplish compression or encryption of the filesin different manners. For example, in one embodiment, to speed themigration of files, Archive Node Appliance may provide hardware supportfor such encryption or compression. Embodiments of methods and systemsfor such encryption or compression are discussed in U.S. patentapplication Ser. No. 12/025,081, entitled “System and Method ForEnabling Encryption”, by Robert C. Sims, filed on Feb. 4, 2008 which ishereby incorporated by reference for all purposes.

Additionally, if a policy 428 associated with the file specifies thatmultiple copies of a file are to be maintained a second tape on which tostore the file may be determined and the file migration module 426 mayuse LTFS module 424 to copy the file from data store 418 to the secondtape at a location on the second tape which corresponds to the locationof the file as presented through the FUSE file system. Notice here thattwo separate tapes may have the file stored using an LTFS file systempath that mirrors the path of that file as presented through the FUSEfile system. Furthermore, if a policy associated with the file specifiesthat the file is to be replicated the file may also be sent to anotherArchive Node Appliance, as will be discussed in more detail.

In addition to storing files on the tape, the archive node appliance maystore file system metadata of the FUSE file system (or other filesystem) on the tape in addition to the metadata stored according to theLTFS file system. The metadata stored may include information necessaryfor the FUSE file system of another archive node appliance to presentfiles from the tape in a similar manner as the FUSE file system of theoriginating archive node appliance, including associating the file withthe same users, policies, etc.

When a command to read a file is received, map 442 may be consulted todetermine the location of the file (e.g., whether it is located in datastore 418, on a tape in the tape library 410 or both). If the requestedfile is completely on the data store 418, I/O operations module 432 mayrespond to the read of the file using the file as stored in the datastore 418. If the file is on a tape (and not entirely in the data store418), the tape on which the file is located may be determined using themap 442. The index 436 and the library control module 434 can then beutilized to determine if the tape is in a drive, and if not, to load theappropriate tape into a drive of the tape library 410. The file systemon the tape may be mounted using LTFS management module 432. I/Ooperations module 422 can then use LTFS module 424 to access the file onthe tape and respond to the read of the file.

It will be noted here that certain actions may be taken in associationwith the read file before the file is used to respond to the read. Inparticular, in certain embodiments, actions associated with one or morepolicies applicable to the file may be performed. For example, if apolicy that applies to the file specifies that the file should becompressed, the file may be decompressed as the file is read from thetape and before the file is used to respond to the read of the file. Inone embodiment, the use of LTFS may simplify this decompression.Specifically, the tape on which the file is stored may be formatted tostore compressed data. The presence of this type of tape in the drivemay indicate to the LTFS module 424 that data stored on the tape iscompressed. The LTFS module 424 may thus configure the drive holdingthat tape such that when the file is read from the tape using LTFSmodule 424 it is decompressed.

Similarly, if an applicable policy specifies that the file is to beencrypted the file may be decrypted before the file is used to respondto the read of the file. As LTFS may not support encryption, in oneembodiment, decryption of the file being stored may be accomplished bythe tape drive in which the appropriate tape is located. Specifically,before mounting the LTFS file system on the tape on which the file isstored one or more commands (for example, SCSI or other types ofcommands that may or may not include key information to be utilized) maybe sent to the drive to cause it to decrypt the file. The LTFS filesystem can then be mounted on the tape. LTFS can then be used to readthe file while the tape drive handles the decryption of the datatransparently to LTFS. The file is then used to respond to the read ofthe file.

If the file is located on the tape and the FUSE file system does notcontain metadata for the file, the FUSE file system metadata stored onthe tape can be read and stored. Consequently, if files on the tape wereoriginally stored by a first archive node appliance and the tape read bya second archive node appliance, the file system of the second archivenode appliance will have the information necessary to describe thefiles, including information not typically maintained or used by theLTFS file system of the tape.

In many cases, however, if the file is located on tape, it may take arelatively long amount of time to access the file. This situation may beexacerbated if, for example the file system on the tape is not currentlymounted, the tape itself is not currently in a drive of the tapelibrary, the tape is currently positioned at a location far away fromthe location where the file is located, etc. These conditions can resultin an access time for a file on tape that is on the order of minutes.

Many network based file system protocols have timeout conditions. Forexample, in the CIFS protocol, an OPEN or a READ command must beresponded to within 30 seconds or a timeout condition will occur. Thetimeout condition may be dependent on the type of network file systemsused. In some cases, the timeout period is negotiated between a host andfile system. Thus, the Archive Node Appliance 400 can be configured tonegotiate the timeout time with hosts. The timeout time can be set in aconfiguration setting for Archive Node Appliance 400. As a result, thetime period for responding to such a command may be less than thatneeded to access the file on the tape. In order to present network basedfile systems based on these types of protocols such conditions may needto be addressed.

To that end, in some embodiments, read cache 450 may be maintained ondata store 418. Read cache 450 may comprise the first portion 452 ofeach file stored using the network based file system presented by theArchive Node Appliance 400. When a file is read, then, if any portion ofthe file is to be read from tape the first portion 452 of the read filethat is stored in the read cache 450 may be used to respond to the read,while substantially simultaneously accessing the file on the tape. Sincethe first portion 452 of the file is stored in the read cache 450 on thedata store 418 it can be accessed quickly enough that a timeout oncommands can be avoided while the file on the tape is accessed. Theremainder of the file can then be read from the tape and used to respondto the commands. The size of the first portion 452 of each file may beuser configurable, based on system parameters, or defined in some othermanner.

It will be noted that the read cache 450 may comprise first portions 452of none, all, or some subset of, the files that are stored inconjunction with the network based file system. For example, if datastore 418 is corrupted or otherwise unusable, when the data store 418 isreplaced read cache 450 may comprise first portions 452 of none of thefiles. The read cache 450 may then be repopulated as files are accessedby users through the network based file system. During this repopulationthen, read cache 450 may comprise first portions 452 of some subset ofthe files that are stored in conjunction with the network based filesystem.

Accordingly, in some embodiments, when a file is read if any portion ofthe file is to be read from tape it can be determined if the firstportion 452 of that file is in the read cache 450. If it is that firstportion 452 may be used to respond to the read as detailed above. If,however, the first portion 452 of the read file is not in read cache450, the file may be read from tape and used to respond to the read.Additionally, the file data read from tape may be used to repopulate theread cache 450 by storing the first portion 452 of the read in the readcache 450 at that time (embodiments of which will be discussed in moredetail below).

In one embodiment, as a CIFS command may have a 30 second timeout periodand an average or poor timing scenario for a tape access may be on theorder of 4 minutes, the first portion 452 of each file stored in theread cache 450 may comprise the first 512K of each file. In oneembodiment, the read cache size may be based on directories provided bythe FUSE module 412 so that all the files within the directory are aparticular size. If the directory is presented as a share, the policythus applies to files within the share. In another embodiment, the sizeretained on read cache 450 may be dependent upon the size of blocks thatmay be read in a single operation via the network file system, the settime for a timeout and the time required to load, mount and position atape with the requested file. It will be noted that the data in the readcache 450 may be stored in a manner corresponding to the format in whichthe file is stored on the tape. Thus, for example, if the file iscompressed when it is migrated to tape the read cache 450 may comprisethe first portion 452 of the file in compressed format, where this firstportion equals approximately 512 k of data when uncompressed.

Initially then, when a host device using a CIFS based file systemprovided by the Archive Node Appliance wishes to read a file it may sendan OPEN command to the Archive Node Appliance 400. I/O operations module422 may determine if the requested file is completely in the data store418 using map 442. If so, I/O operations module 422 may respond to theread of the file using the file in the data store 418.

If however, the file is on a tape, the tape on which the file is locatedmay be determined using the map 442. The I/O operations module 422 canthen initiate the load and access of the file on the tape using thelibrary control module 434 and the LTFS management module 432. I/Ooperations module 422 delays the response to the initial OPEN commandfor a time period less than the timeout associated with the receivedcommand. In some embodiments, this time period may be the longest timeperiod that does not result in a timeout occurring (e.g., 20 seconds, 29seconds in the case of CIFS commands, or another time period in the caseof commands in other protocols, etc.).

The host device may subsequently send a READ command for a certainamount (e.g., 64K or a different amount) of the file to the Archive NodeAppliance 400. I/O operations module 422 can delay the response to thisREAD command as long as possible without a timeout resulting (e.g., 20second, 29 seconds, in the case of CIFS commands, or another time periodbelow the 30 second timeout in the case of commands in other protocols).After the delay, the I/O operation module 422 will respond to thecommand with the data requested. The I/O operations module 422 maycontinue to delay responses to subsequent READ commands and utilize datafrom the read cache 450 to respond to the READ commands until data fromthe first portion 452 is exhausted or the LTFS file system on theappropriate tape is mounted and the file on the tape can be accessedusing LTFS module. The I/O operations module may continue to delayresponses and dynamically switch between delaying responses and notdelaying responses as needed.

In addition to delaying responses, Archive Node Appliance 400 can returnless data than requested by the host. For example, Archive NodeAppliance 400 may return 1K instead of the requested 64K. WhetherArchive Node Appliance 400 returns less data than the amount requestedmay depend on the network file system protocol, host operating system orother factors. Returning less data than requested provides the advantagethat the read cache can be smaller.

I/O operation module 422 may then use LTFS module 424 to access the fileon the tape and respond to subsequent READ commands for the file. Morespecifically, in one embodiment I/O operations module 422 may utilizeLTFS module 424 to access the file on the appropriate tape and read thefile from the tape into buffer 444. Subsequent READ commands for thefile may be responded to using the data in the buffer 444.

Furthermore, in some embodiments, in addition to reading the file intobuffer 444 the file may also be read into a file cache 460 on the datastore. File cache 460 may be an area on data store utilized fortemporary storage of files and may be managed according to almost anycache management technique desired. In certain cases if a host does notrequest data of the file at a particular rate (e.g., does not issue READcommands frequently enough, or the READ commands do not request acertain amount of data, etc.), after a certain number of READ commandsI/O operations module 422 may respond to subsequent READ commands forthe file using data of the file from the file cache.

In certain embodiments the opposite may also occur. More specifically,in some instances the reading of file data to the file cache 460 inaddition to reading the file into buffer 444 may slow the response torequests for data from the host. In this case, reading the file datainto both buffer 444 and file cache may mean that data cannot bedelivered at the rate the user is requesting the data or may otherwiseslow the response to user requests. Here, the reading of the data of thefile into the file cache 460 may be stopped before the entire file is inthe file cache such that requests for the file may be serviced morequickly. Thus, the portion of the file that is in file cache 460 maycomprise none, some, or all, of a file.

In one embodiment, the file may be stored in the file cache 460 byappending any portions of the file which are read from the tape to thefirst portion 452 of the file in the read cache 450 if such a firstportion of the read file exists in read cache 450. Thus, if the firstportion 452 exists in the read cache 450 when any portion of the filenot comprised by first portion 452 in the read cache is read from thetape it may be appended to the first portion 452 already stored in theread cache 450. In either case (the first portion 452 does, or does not,exist in the file cache) the entire file may be stored in the file cache460 when the file is read. Thus, at a later point, if portions of thefile are deleted from the file cache 460 the first portion 452 of thefile may be left on the data store 418 such that the first portion 452of the file is in read cache 450. Accordingly, the read cache 450 willbe repopulated with the first portion of that file if the first portion452 was not in the read cache 450 before the file was read.

It may be useful to discuss embodiments of the storage of mapping data,index data, policies, file meta-data, tape-library data, etc. that maybe utilized by an Archive Node Appliance. Embodiments of such storagemethods and formats may be used, for example, to store the map, indexand policies as discussed above. FIGS. 5A-5D depict one embodiment of aschema for a database that may be utilized in conjunction withembodiment of an Archive Node.

Turning first to FIG. 5A, one embodiment of a table schema for thestorage of data relating to files and directories is depicted. In thisschema, there is a node table 502, a storage location table 504, astorage media table 506, a disk table 508, a storage type table 510, alocation statuses table 512, a Disk to Tape File System (used to referto embodiments of an implementation of a file system using an ArchiveNode, also known by the acronym DTFS) settings table 516, DTFS userstable 518, DTFS groups table 520, tape drives table 522, tapes table 524and storage method types table 526.

Storage locations table 504 may comprise information on locations wheredata can be stored in conjunction with an Archive Node and thus entriesin the storage location table 504 may be linked to entries in thestorage media table 506. Entries in storage media may, in turn, belinked to entries in the disk table 508 that are associated with a datastore of the Archive Node and entries in tapes table 524 that areassociated with tapes in the tape library of the Archive Node. Entriesin storage locations table 504 may also be linked to entries in tapedrives table 522 that are associated with drives in the tape library ofthe Archive Node. Entries in the storage location table 504 may also beassociated with a state and a status as represented by entries in thelocation states table 514 or the location statuses table 512.

Nodes table 502 comprises entries which are associated with a file or adirectory as presented by the FUSE file system. In general the top leveldirectory used by a FUSE file system of an archive node appliance can bea universally unique identifier (UUID) associated with the archive nodeappliance. Examples of such an identifier include, but are not limitedto, a serial number, a software license number or other uniqueidentifier. The use of a UUID as the top level directory by archive nodeappliances ensures that path names to files stored by that archive nodeappliance will not conflict with the path names used at a second archivenode appliance if the tape if transferred to the second archive nodeappliance.

Entries in the node table 502 are linked with entries in the DTFS userstable 518 where these entries may represent users of the DTFS filesystem (which may be defined by an administrator, based on the networkbased file system implemented by the Archive Node, etc.). Each of theentries in node table 502 may also be linked with entries in the storagelocation table 504 such that a link between an entry in the node table502 associated with a file or directory may be linked with one or moreentries in the storage location table 504 associated with a disk or tapewhere that file or directory is stored.

In the case in which an archive node appliance is part of a WindowsActive Directory domain, active directory does not use Unix-like userIDs and group IDs to identify users. Active directory uses stringsreferred to as security identifiers (SID) for this purpose. Accordingly,the DTFS user table 518 and DTFS groups table 520 may include an entryfor a user group SID that links the SID to the DTFS user id and, ifapplicable, to the appropriate Unix user ID (UID) and group ID (GID).

Moving now to FIG. 5B one embodiment of a table schema for the storageof data relating to tapes and tape libraries of an Archive Node isdepicted. In this schema, there is a tapes table 524, tape locationstable 532, libraries table 530, tape statuses table 542, tape typestable 540, library statuses table 562, library states table 560, tapelocation types table 558, mailbox table 538, slot table 536, tapesessions table 554, tape micro sessions table 556, tape drive typestable 546, tape drives table 534, tape drive affinities table 552, tapedrive statues table 548 and tape drive states table 550.

Entries in tapes table 524 may be associated with an entry in tapelocations table 532 associated with a location of tape in a tape library(for example, a slot, drive, etc.). Each of the entries in tape locationtable 532 may be associated with an entry in slot table 536 associatedwith a slot in a tape library or an entry in tape drives table 544associated with a drive in the tape library. Furthermore, entries intape locations table 532 and tapes table 524 are linked with an entry inlibraries table 530 associated with a tape library of the Archive Node(of which there may be one or more, as discussed above). In this manner,an entry in tapes table 524 associated with a tape can be associatedwith an entry in library table 530, slot table 536 or tape drive table544 associated with the location of that tape.

Entries in tape drive table 544 may be also linked to an entry in tapedrive types table 546 associated with a type of the drive, or an entryin tape drive statuses table 548 or tape drive states table 550associated with a statuses or state of a tape drive. Entries in tapestable 524 may also be linked to entries in tape status table 542 andtape types table 540 associated with a type or a status of a tape.

Turning to FIG. 5C one embodiment of a table schema for the storage ofdata relating to policies applicable to directories in an Archive Nodeis depicted. In this schema, there is nodes table 502, directorypolicies table 564, policies table 566, policy types table 568, policyvalues table 570 and policy arguments table 572. Entries in directorypolicies table 564 may be associated with polices to be applied todirectories (and thus to files stored in those directories). Entries indirectory policies table 564 may be linked to entries in node table 502associated with a directory. In this manner, entries in directorypolicies table 564 associated with policies to be applied to directoriesmay be linked to entries in nodes table 502 associated with a directoryagainst which that policy is to be applied. It will be noted that asimilar schema could be utilized to associate file policies with files,share policies with shares, etc.

Entries in directory policies table 564 may also be linked to an entryin policies table 566 that may be associated with a particular policy.Entries in policies table 566 may, in turn, be linked with an entry inpolicy types table 568 that is associated with a type of policy (forexample, encryption or compression policy, number of copies to keep,replication, etc.). Thus, an entry in policies table 566 associated witha particular policy may be linked with an entry in policy type table 568associated with the type of that policy.

FIG. 5D depicts one embodiment of a table schema for collecting data onnodes in an Archive Node. In this schema, there is nodes table 502,ingest rates table 574 and reporting durations table 576. Thus, entriesin the node table 502 can be linked to entries in ingest rates table 574associated with statistics on the creation, reception, storage,migration, etc. of a file or directory.

FIG. 5 is provided by way of example and not limitation and the archivenode appliance may store other metadata for files, directories, users,etc. According to one embodiment, for example, the FUSE file system maysupport extended attributes that are not used directly by the FUSE filesystem, but can be stored by clients and exposed through the FUSE filesystem. Extended attributes for a file or directory may be stored in thenode table 502 for the file or directory other table. For example, amedia management system may organize files based on the type of projectwith which the media is associated and therefore include an extendedattributes such as project:soundtrack for files.

From a review of the above, it will be apparent that embodiments of suchArchive Nodes may provide a highly effective manner of implementing anetwork based file system using a tape library. In some instances,however, it may be desired to provide a high level of availability orincreased performance in conjunction with network based file systems. Assuch, in certain embodiments Archive Node Appliances may be clustered toprovide increased performance or a higher degree of fault tolerance.

Referring now to FIG. 6, a method for storing a file using an embodimentof an Archive Node, including an Archive Node Appliance is depicted. Atstep 610 a request (which may comprise multiple commands in a filesystem protocol) to store a file may be received at the Archive NodeAppliance, where the file may be associated with a name and a path asvisible through the network based file system implemented by the ArchiveNode Appliance. For example, the path of the file may be path/patient_records and the file name may be Patient1.doc. The file is thenstored on a location on the data store of the Archive Node Appliance atstep 620, where the file may have a different name and be located at apath associated with the data store. For example, the path of the fileas stored on the data store may be /data3 and the file name may be550e8400-e29b-41d4-a716-446655440000.

In one embodiment, as discussed above, the file is stored in the datastore according to one or more policies that apply to that file. Forexample, if a policy that applies to the file (for example, the policyis associated with the location associated with the network based filesystem where the file is stored) specifies that the file should becompressed the file may be compressed before the file is stored in thedata store. Similarly, if an applicable policy specifies that the fileis to be encrypted the file may be encrypted before it is stored in thedata store.

The map can then be updated at step 630 to associate the name and thepath of the file as visible through the network based file system withthe path and name of the file as stored on the data store. Thus, in thisexample the path /patient_records and file name Patient1.doc, as visiblethrough the network based file system is associated with the path /data3and file name 550e8400-e29b-41d4-a716-446655440000 associated with thefile as stored in the data store.

Subsequently, one or more policies to be applied to the file can bedetermined at step 640. The policies may be applied in conjunction withthe migration of the file at step 650. As discussed above, in oneembodiment one policy may specify that a migration timeout period is tobe applied to the file before the file is migrated. This migrationtimeout period may specify a time period such that an amount of timeequal to the migration timeout period may be allowed to elapse beforethe file is migrated. Thus, if such a policy exists the migrationtimeout period may be allowed to elapse before the file is migrated.

To migrate the file, one or more tapes on which to store the file may bedetermined. This determination may be based on the policies that havebeen determined to apply to that file. For example, the number of tapesdetermined may be based on a policy specifying that the file is to bemaintained on multiple tapes. If so, two different tapes on which tostore the file may be determined. If a policy to apply to the filespecifies that the file is to be encrypted a tape comprising encrypteddata may be selected. Similarly, if a policy to apply to the filespecifies that the file is to be compressed a tape comprising compresseddata may be selected. Assume for purposes of example that the tape onwhich it is determined to store the file has a TapeID of AN02394.

Each of the tapes on which it is determined to store the file can thenbe loaded into a drive, if it is not already in a drive, and the LTFSfile system mounted. Specifically, the tape may be located using theindex that maintains the location of each of the tapes in the libraryand loaded into a drive. The file can then be copied from its locationon the data store to a location on the tape. In one embodiment, a paththat corresponds to the path of the file as visible through the networkbased file system may be created on the tape using the LTFS file systemif it does not already exist. The file can then be saved using the namethat corresponds to the name of the file as visible through the networkbased file system. Continuing with the above example, the path/patient_records may be created on the tape having TapeID AN02394 if itdoes not exist and the file may be saved as Patient1.doc on this tape.

In one embodiment, before or during the copying of the file to themounted LTFS file system on the tape, actions may be taken to implementpolicies applicable to the file. For example, if a policy specifies thatthe file is to be replicated it may be sent to another Archive NodeAppliance or if a policy that applies to the file specifies that thefile should be compressed, the Archive Node Appliance can cause the fileto be stored on a compressed tape. Similarly, if an applicable policyspecifies that the file is to be encrypted the Archive Node Appliancecan cause the file to be stored on an encrypted tape.

The map can then be updated at step 660 to associate the tape on whichthe file is stored, the name and the path of the file as visible throughthe network based file system, the path and name of the file as storedin the data store and the path and name of the file as stored on thetape. Thus, in this example the path /patient_records and file namePatient1.doc, as visible through the network based file system isassociated with TapeID AN02394, the path /data3 and the file name550e8400-e29b-41d4-a716-446655440000 associated with the file as storedin the data store.

At step 670 the file, or portions thereof, may be deleted from the datastore. In some embodiments, as it is desired to maintain the firstportion of a file in a read cache in the data store, all portions of thefile except this first portion may be deleted from the data store. Itwill be noted therefore, that in certain embodiments, the path and nameof the file in the map that is associated with the file as stored in thedata store may describe the location of the first portion of the filestored in the read cache. The steps of FIG. 6 can be repeated as neededor desired.

When an LTFS file system writes files to the tape, it will storesufficient metadata for an LTFS file system to describe the files (e.g.,to an operating system). However, the regular attributes stored by theLTFS file system would be inadequate to describe the tape for purposesof the FUSE file system. Thus, if a tape is transferred from one archivenode appliance to another, the files could be read by the archive nodeappliance. However, using the LTFS regular attributes alone, the FUSEfile system of the second archive node appliance would have inadequateinformation to present the files to the operating system (and throughthe network file system interface) in the same manner as the FUSE filesystem of the originating archive node appliance because the secondarchive node appliance would lack the appropriate DTFS metadata.Consequently, there is a need for self-describing tapes that includessufficient information for the FUSE file system of one archive nodeappliance to properly describe files stored by another archive nodeappliance.

Accordingly, an archive node appliance can write DTFS file, directoryand other metadata (such as metadata depicted in FIGS. 5A-D) to the tapefor the files stored on the tape. According to one embodiment, the DTFSmetadata may be written as extended attributes on files and directoriesof the LTFS tape. According to another embodiment, the DTFS metadata maywritten as a file to the tape.

Turning first to the use of extended attributes, extended attributes area feature of many file systems, including LTFS. In general, extendedattributes are attributes that enable users to associate computer fileswith metadata that the file system does not interpret, unlike regularattributes which have a purpose specifically defined by the file system.Extended attributes are often stored as name/value string pairs andassociated with files or directories.

Because extended attributes are user definable, DTFS metadata can bestored as LTFS extended attributes on the tape. In general, the DTFSmetadata can be written as extended attributes in any manner that issupported by the tape file system. Metadata which corresponds to filesor directories can be stored as extended attributes directly on thosefiles, metadata which corresponds to directories can be stored asextended attributes on the directories of the LTFS file system andmetadata which corresponds to the entire tape can be stored as extendedattributes on the root directory of the tape.

The tape file system may place limits on the ability to define extendedattributes. For example, one limitation of some embodiments, is thatextended attributes must reside in an appropriate namespace in order forthe file system to write the extended attributes. In someimplementations of LTFS for example, extended attributes may only bewritten into the “user” namespace (including a nested namespaces).Therefore, according to one embodiment, DTFS metadata may be stored in adesignated name space such as user.dtfs. Furthermore, the extendedattributes have to meet other formal requirements of the file system,such as name length, string size, character encoding etc.

For purposes of explanation, the extended attributes can be classifiedas basic information, which applies to the entire tape, file nodesmetadata, which applies to files, and directories metadata, whichincludes any metadata associated with directories on a tape. Turningfirst to basic information, examples of basic information include anidentification of the system that most recently synced the tape (e.g.,the serial number of the archive node appliance that most recentlysynced the tape.) Using the namespace discussed above, an example of anextended attributed may be:

-   -   “user.dtfs.mostrecentapplianceSN:000001”

Another example of basic information metadata may include an activedirectory domain if files on the tape were stored by a system that waspart of an active directory domain. An example of such an extendedattribute may be:

-   -   “user.dtfs.ArchiveDirectoryRealm:COMMSTOR.Company.com”

Turning to individual files on the tape, the files can be stored withthe same directory and file names as presented by the FUSE file systemand over the network file system interface. File node metadata anddirectories metadata are attached directly to the files and directories,respectively. For a file or directory, attributes from the correspondingrow in nodes table 502 can be attached to the file or directory asextended attributes. Table 1 below provides examples of information fromthe DTFS database mapped to settings for file node extended attributes(string length, data format):

TABLE 1 LTFS Information Information from the Database Typical ExtendedDatabase Xattr String Attribute Nodes table column Data Type ValueLength Data Format deleted Boolean 1 t or f original_size Bigint 13Unsigned Int last_access_time timestamp 29 Date as with time zone Stringlast_modification_time timestamp 29 Date as with time zone Stringlast_status_change timestamp 29 Date as with time zone String hash_codeBytea 128 Hexidecimal hash_algorithm 255 char 6 String stringcompressed_algorithm 255 char 0 String string user_permissions Smallint1 Unsigned Int 0 . . . 7 group_permissions Smallint 1 Unsigned Int 0 . .. 7 world_permissions Smallint 1 Unsigned Int 0 . . . 7 dtfs_user_idBigint 1-6 Unsigned Int dtfs_group_id Bigint 1-6 Unsigned Int

One example embodiment of a file node attribute is shown below:

-   -   user.dffs.original_size:1024        It can be noted that, in this example, the extended attribute        name matches the attribute name in the database to make for        simple mapping between database entries and extended attributes.        In other embodiments, the extended attribute name may differ        from the metadata name in the DTFS database, with the archive        node maintaining a mapping between DTFS attribute names and        extended attribute names.

Table 1 is provided by way of example, and other DTFS metadata may bemapped to extended attributes as needed or desired. Furthermore, thelength and data types of the extended attributes may be set as needed ordesired. Thus, for example, while the database field is set to null, thedatabase field may have a non-zero length in other embodiments.

For each directory on the tape, the name of the directory from the nodestable 502 can be used as the name of the directory on the tape. Databaseattributes from the corresponding row in nodes table 502 can be attachedto the directory as extended attributes. Table 2 below provides examplesof information from the DTFS database mapped settings for directoryextended attributes (string length, data format):

TABLE 2 LTFS Information Typical Extended Information from the DatabaseString Attribute Nodes Table Column Data Type Value Length Data Formatdeleted Boolean 1 t or f original_size Bigint 13 Unsigned Intlast_access_time timestamp 29 Date as with time zone Stringlast_modification_time timestamp 29 Date as with time zone Stringlast_status_change timestamp 29 Date as with time zone Stringuser_permissions smallint 1 Unsigned Int 0 . . . 7 group_permissionssmallint 1 Unsigned Int 0 . . . 7 world_permissions smallint 1 UnsignedInt 0 . . . 7 dtfs_user_id bigint 1-6 Unsigned Int dtfs_group_id bigint1-6 Unsigned Int

An example of a directory attribute according to one embodiment may be:

-   -   “user.dtfs.group_permissions:777”        Table 2 is provided by way of example, and other DTFS metadata        may be mapped to extended attributes as needed or desired.        Furthermore, the length and data types of the extended        attributes may be set as needed or desired. Again, the extended        attribute names and DTFS attribute names may match or be mapped        to each other.

DTFS may provide for its own extended attributes which can also bemapped to extended attributes of the LTFS. Consequently, for a file,there may exist information in the database (e.g., rows in the table)which represents client provided metadata not directly used by the FUSEfile system. Using the example in which a media system provides metadatasuch as project:music for files, the DTFS extended attribute can bestored as an LTFS extended attribute.

user.dtfs.attributes.linux.0.name.project:soundtrack

The FUSE file system may also maintain extended attributes on a file ordirectory that are internal to the DTFS. Examples may include, forexample, “cachedtime,” file retention policy or delayed action state.Internal extended attributes may also be written to the tape as LTFSextended attributes. One example of a form for writing internal extendedattributes is:

-   -   user.dtfs.attributes.dtfs.attribut_name:attribute_value

Furthermore, user and group name mappings between FUSE file system usersand groups and active directory SIDs may be stored as extendedattributes of, for example, the root directory of the tape. An exampleextended attribute is shown below:

user.dtfs.ad.uid.1000000:S-1-5-21-17264431-51382897-1586563796-6869,jsmithIn this example, the portion of the attribute name uid.100000 representsthe Unix Id of the user, the portion of the value string“S-1-5-21-17264431-51382897-1586563796-6869” represents the SID and theportion of the value string “jsmith” after the comma represents the nameassociated with the SID if known. In a similar manner, group ids can bemapped to active directory information as shown in the example below:

-   -   user.dtfs.ad.gid.1000001:S-1-5-32-100, Administrator        where 1000001 represents the UNIX group ID, S-1-5-32-100        represents the active directory group SID and Administrator is        the group name.

In the above examples, the DTFS database attribute names meet thelength, naming criteria for LTFS extended attributes, allowing aone-to-one mapping. However, in some cases, DTFS attribute names may belonger that provided for by LTFS. This may be particularly true whenusers define DTFS extended attributes.

Consequently, DTFS attributes name:value pairs may be split intomultiple LTFS attributes. To provide one example, the DTFS extendedattribute project:soundtrack may be stored as the two LTFS extendedattributes:

-   -   user.dtfs.attributes.linux.0.name.project    -   user.dtfs.attributes.linux.0.value.soundtrack

This split can be done to allow for extended attribute value nameslonger than 255 characters (as may be supported by DTFS) and to overcomethe limitation in LTFS that extended attribute names cannot include acolon. In other embodiments, it may not be necessary to split a DTFSextended attribute into two LTFS extended attributes.

Thus, according to one embodiment, an archive node appliance canmaintain file system metadata for the FUSE file system that can be usedby FUSE file systems to describe the file. When a file is stored on atape using an LTFS file system, the archive node appliance can storemetadata interpreted by the LTFS file system to describe the files(regular attributes) plus file system metadata used by the FUSE filesystem to describe the files. The FUSE file system metadata can bestored as extended attributes of the LTFS file system.

The metadata stored as extended attributes can be limited to themetadata attributes that do not overlap between the LTFS file system andFUSE file system. For example, if a file is stored on the tape with thesame file name that is used to present the file by the FUSE file system,there is no need to store the filename in both the LTFS regularattributes and the LTFS extended attributes, though such duplicativeattributes could be stored.

FIG. 7 is a flow chart illustrating a more detailed embodiment ofwriting files to a tape. For purposes of explanation, a set of one ormore file to be written to tape from the data store or memory arereferred to as a “file chain.” It is assumed for purpose of FIG. 7 thatthe appropriate media to which files are to be written is mounted in adrive.

At step 700, the archive node can select the first file to be written tothe tape in a write chain and, at step 702, determine if every directoryas exposed by the FUSE file system in the path to the file exists. Thus,for example, if the file is exposed by the FUSE file system as beingavailable at UUID1/documents/document.txt, the archive node appliancewill determine if the directories “UUID1” and “/documents” exist on thetarget tape. If the directories do not exist on the target tape, themetadata for all missing parent directory nodes of the file are gathered(e.g., from the DTFS database) (step 704). The directories can becreated and the metadata from the FUSE file system stored in theextended attributes of the LTFS index in memory corresponding to thetarget media (steps 705, 706). According to one embodiment, metadatawill not be added or modified for existing directories on tape.

When all the parent directories of the file are created and the DTFSmetadata for the directories stored in the LTFS extended attributes, theselected file can be written to the tape (step 707). If the write is notsuccessful, error handling can occur (step 708). If the write issuccessful, the DTFS metadata for the file can be written into the LTFSextended attributes for the tape (step 710). This can include writingregular attributes of the DTFS, extended attributes of the DTFS,SID/UID/GID mappings or other information stored as part of the filesystem metadata for the FUSE file system. If writing the FUSE filesystem metadata to the LTFS extended attributes is unsuccessful, errorhandling can occur (step 712). If the DTFS metadata is successfullywritten to the tape, the process can be repeated for each file in thefile chain (represented at decision block 714).

When all the files in a file chain are written and the DTFS filemetadata set as extended attributes, the archive node appliance canwrite the basic information metadata that applies to the entire tape asextended attributes of the root directory of the media (step 716). AnLTFS sync operation can then be performed (step 718) to write the indexfile in memory to the media. If the sync is unsuccessful error handlingcan occur (step 720). If the sync is successful, the process can berepeated for each write chain (step 722). Multiple write chains mayoccur, for example, at different time periods. In other embodiments, thearchive node appliance may create multiple write chains if there are alarge number of files to be written to a media so that an LTFS syncoccurs at multiple times before all the files are written. When writingto a tape is complete, the tape can be unmounted and the most recentindex file copy stored from the most recent LTFS sync is stored as theindex file on the tape (step 724). The steps of FIG. 7 can be repeatedas needed or desired.

Accordingly, the tape may contain enough DTFS metadata for the files anddirectories so that a second archive node appliance can recreate theappropriate portions of the DTFS database for the files on the tape andthe FUSE file system of the second archive node appliance can presentthe files in the same manner as the first archive node system with theappropriate users, permissions, etc. applied.

In addition to storing information that allows separate FUSE filesystems to describe files on the tape in the same manner, the archivenode appliance may store additional information to ensure data integrityand interoperability of the tape from one archive node appliance toanother. One concern with data integrity is that a user may attempt tomodify the contents of a tape with an unauthorized LTFS system. LTFS,however, records an index generation value every time the tape issynced. This index generation value is stored as part of the index onthe tape. Once a sync is complete and/or prior to unmounting the tape,the archive node appliance can store the index generation value in anonboard memory chip (MAM) of the tape cartridge. In addition, LTFS alsodefines a volume UUID for a tape each time the tape is formatted. Thearchive node appliance can also store this tape UUID in the MAM data ofthe tape cartridge.

When an archive node appliance loads the tape, the archive nodeappliance can read the index generation value and volume UUID from theMAM data, as well as the index generation value and volume UUID from thetape index. If the values read from the MAM data do not match the valuesread from the tape index, this indicates that the tape has been writtento or changed by a system that is not aware of the index value in theMAM data. This at least indicates that the tape left the archive nodeappliance ecosystem and suggests that the tape was accessed and changedby an unauthorized system. When a discrepancy between the indexgeneration value in the MAM data and index generation value in the tapeindex is detected, the archive node appliance may generate an alert ortake other action.

Although the archive node appliance may be configured to check the indexgeneration values individually, or check the volume UUID's individuallythese actions may not be sufficient to ensure the integrity of the tape.For example, whenever a tape is modified, LTFS increases the indexgeneration value, so a comparison of the index generation values on thetape and in the MAM data would detect the change, but a comparison ofthe UUID's on the tape and in the MAM data would not. If the tape werereformatted to reset the index generation value before modifying thedata, the tape could be modified a sufficient number of times to causethe index generation values to match, so a comparison of the indexgeneration values on the tape and in the MAM data would not detect thechange. Because, however, the reformatting of the tape would cause anew, unique UUID to be generated and assigned to the tape volume, acomparison of the UUID's on the tape and in the MAM data would detectthe change. Comparison of both the index generation values and UUID's onthe tape and in the MAM data would be sufficient to detect the change ineither case. Detection of a change would indicate that the tape wasreformatted by an unauthorized system.

These scenarios assume that someone who makes an unauthorizedmodification to the tape will not change the values of the indexgeneration value and UUID in the MAM data. If it is desired to preventthis possibility, the index generation value and UUID in the MAM datacan be protected by generating a hash, a checksum, or some otherverification data for these values and storing the verification data inthe MAM memory as well. Because someone attempting to alter the indexgeneration value and UUID in the MAM data would not know the algorithmby which the verification data was generated, it is highly unlikely thatit would be possible to generate appropriate verification data formodified index generation value and UUID values.

Another issue that may occur is that the metadata maintained by anarchive node appliance for files, directories, users etc. may changeover time such that files on the tape are stored using one generation ofmetadata whereas the archive node appliance accessing the tape usesanother generation of metadata. To account for this possibility, ametadata version can be stored in the MAM data of the tape or as anextended attribute in the index of the tape. When an archive nodeappliance supporting a newer version of the DTSFS metadata writes to atape having an older version of the DTFS metadata, the archive nodeappliance can update the metadata for each file and directory with thenewer version of the DTFS metadata. When an archive node appliancesupporting an older version of the DTFS metadata reads a tape having anewer version of the DTFS metadata, the archive node appliance can markthe tape as “read only,” and populate its DTFS database with only theversion 1 attributes on the tape to present the files on the tapethrough the FUSE system interface.

Advantages of storing DTFS metadata in the extended attributes of anLTFS tape can better understood in the context of FIG. 8, which providesa diagrammatic representation of one embodiment of data stored on a tapeaccording to an LTFS system. The data on the tape 800 can include anindex file 805 and file data 810 for other files (generally thenon-index files of interest to end users, such as documents, etc.).

When a tape is mounted the index file 805 is read into memory for fastaccess. The extended attributes may be embodied as elements (e.g., XMLelements) in index file 805. Consequently, the DTFS metadata will residein memory for faster access. As files are changed, added, deleted, movedetc. the metadata for the files can be quickly updated in the index fileRAM.

Furthermore, LTFS supports sync operations in which the current copy ofthe index file in RAM is written to tape (e.g., as index file copy 815).Consequently, the current copy of DTFS metadata for files written totape can be stored as index file copy 815 from time to time as the tapeis mounted. This helps preserve the state of the index in case of powerfailure or other error. When the tape is unmounted, the LTFS systemstores the latest index file copy 815 as index file 805 thus updatingindex file 805 with the most current DTFS metadata. When a tape ismounted, the LTFS system checks if the latest index file copy 815matches index file 805. A discrepancy between the two can indicate sometype of error, such as a power loss before the tape was unmounted. Sucha discrepancy may lead to a mount error generated by the LTFS system.The archive node appliance can check for the mount failure andautomatically run error recovery if required. For example, the archivenode appliance can automatically cause the LTFS utility ltfsck to run torecover the media.

While it may be preferable to store DTFS metadata in the extendedattributes of an LTFS tape, the DTFS metadata may also be stored as aseparate metadata file on the tape separate from the LTFS index file.FIG. 9 is a flow diagram illustrating one embodiment of a method forstoring DTFS metadata as a file on the tape. It is assumed for purposeof FIG. 9 that the appropriate media to which a file is to be written ismounted in a drive.

At step 900, the archive node can select the first file to be written tothe tape in a write chain and, at step 902, determine if every directoryas exposed by the FUSE file system in the path to the file exists. Thus,for example, if the file is exposed by the FUSE file system as beingavailable at UUID1/documents/document.txt through the network filesystem interface, the archive note appliance will determine if thedirectories “UUID1” and “/documents” exist on the target tape. If thedirectories do not exist on the target tape, the metadata for allmissing parent directory nodes of the file are gathered (e.g., from theDTFS database) and stored in a metadata file in memory 904. Thedirectories can be created on the tape (step 905) and the DTFS metadatafor the directories written to a metadata file in memory (step 906).

When all the parent directories of the file are created, the selectedfile can be written to the tape (step 907). If the write is notsuccessful, error handling can occur (step 908). If the write issuccessful, the DTFS metadata for the file can be written into themetadata file (step 910). This can include writing standard attributesof the DTSFS, extended attributes of the DTFS, SID/UID/GID mappings orother information stored as part of the file system metadata for theFUSE file system. The process can be repeated for each file in the filechain (represented at decision block 914).

When all the files in a file chain are written, the archive nodeappliance can generate a checksum of the metadata file (step 918). Themetadata file can be written to the tape (step 920) and the checksum tothe cartridge MAM data (step 922). The checksum can be used when a tapeis loaded to determine if the metadata file has been altered. If thereare multiple file chains (as represented by step 924) the process can berepeated, altering the metadata file to account for the new files andaltering the checksum in MAM. When all the file chains are written andthe metadata file and checksums updated to account for all the filechains, the tape can be unmounted. The steps of FIG. 9 can be repeatedas needed or desired.

In the above embodiment, the metadata file is written to the tape whenthere are no files left in a file chain. However, in other embodiments,the metadata file may be updated on the tape periodically andcorresponding checksum updated in MAM.

In the above examples, the DTFS file system metadata is written to thetape, either as part of the LTFS extended attributes or as a metadatafile separate from the LTFS index file. As memory becomes cheaper,however, tape cartridges may include larger amounts of MAM data.Consequently, the DTFS file system metadata may also be stored in MAM.Furthermore, while in the above examples, index generation values,metadata version numbers and metadata file system checksums aredescribed as being written to MAM data, in other examples they may bewritten to the tape.

Thus, embodiments described herein can maintain a set of metadata for afile to describe the file according to a first type of file system(e.g., the FUSE file system). The file can be presented (e.g., to thelocal operating system, network hosts or others) as being a particularlocation based on the metadata used by the first type of file system.When the file is stored on a tape, the file can be stored in a locationthat mirrors the first location using a second type of file system(e.g., LTFS or other tape file system). Metadata used by the second typeof file system to describe the files will generally be stored on thetape as regular file system attributes as part of this process. Inaddition, embodiments described herein can store metadata used by thefirst type of file system (e.g., the FUSE file system) to describe thefile so that the file can be properly presented according to the firsttype of file system on the different machine, with the file associatedwith the appropriate policies, users, etc.

When a tape is imported to a new archive node appliance, the archivenode appliance can read the index and determine if it already hasentries for the files and directories on the tape in its database. Ifnot, the archive node appliance can create new database entries for thedirectories and files using the metadata in the index file and/orseparate metadata file. Consequently, the FUSE file system of the secondarchive node appliance can present to the files in a similar manner tothe network file system interface as the FUSE file system of the firstarchive node appliance.

Although the invention has been described with respect to specificembodiments thereof, these embodiments are merely illustrative, and notrestrictive of the invention. The description herein of illustratedembodiments of the invention, including the description in the Abstractand Summary, is not intended to be exhaustive or to limit the inventionto the precise forms disclosed herein (and in particular, the inclusionof any particular embodiment, feature or function within the Abstract orSummary is not intended to limit the scope of the invention to suchembodiment, feature or function). Rather, the description is intended todescribe illustrative embodiments, features and functions in order toprovide a person of ordinary skill in the art context to understand theinvention without limiting the invention to any particularly describedembodiment, feature or function, including any such embodiment featureor function described in the Abstract or Summary. While specificembodiments of, and examples for, the invention are described herein forillustrative purposes only, various equivalent modifications arepossible within the spirit and scope of the invention, as those skilledin the relevant art will recognize and appreciate. As indicated, thesemodifications may be made to the invention in light of the foregoingdescription of illustrated embodiments of the invention and are to beincluded within the spirit and scope of the invention. Thus, while theinvention has been described herein with reference to particularembodiments thereof, a latitude of modification, various changes andsubstitutions are intended in the foregoing disclosures, and it will beappreciated that in some instances some features of embodiments of theinvention will be employed without a corresponding use of other featureswithout departing from the scope and spirit of the invention as setforth. Therefore, many modifications may be made to adapt a particularsituation or material to the essential scope and spirit of theinvention.

Reference throughout this specification to “one embodiment,” “anembodiment,” or “a specific embodiment” or similar terminology meansthat a particular feature, structure, or characteristic described inconnection with the embodiment is included in at least one embodimentand may not necessarily be present in all embodiments. Thus, respectiveappearances of the phrases “in one embodiment,” “in an embodiment,” or“in a specific embodiment” or similar terminology in various placesthroughout this specification are not necessarily referring to the sameembodiment. Furthermore, the particular features, structures, orcharacteristics of any particular embodiment may be combined in anysuitable manner with one or more other embodiments. It is to beunderstood that other variations and modifications of the embodimentsdescribed and illustrated herein are possible in light of the teachingsherein and are to be considered as part of the spirit and scope of theinvention.

In the description herein, numerous specific details are provided, suchas examples of components and/or methods, to provide a thoroughunderstanding of embodiments of the invention. One skilled in therelevant art will recognize, however, that an embodiment may be able tobe practiced without one or more of the specific details, or with otherapparatus, systems, assemblies, methods, components, materials, parts,and/or the like. In other instances, well-known structures, components,systems, materials, or operations are not specifically shown ordescribed in detail to avoid obscuring aspects of embodiments of theinvention. While the invention may be illustrated by using a particularembodiment, this is not and does not limit the invention to anyparticular embodiment and a person of ordinary skill in the art willrecognize that additional embodiments are readily understandable and area part of this invention.

Any suitable programming language can be used to implement the routines,methods or programs of embodiments of the invention described herein,including C, C++, Java, assembly language, etc. Different programmingtechniques can be employed such as procedural or object oriented. Anyparticular routine can execute on a single computer processing device ormultiple computer processing devices, a single computer processor ormultiple computer processors. Data may be stored in a single storagemedium or distributed through multiple storage mediums, and may residein a single database or multiple databases (or other data storagetechniques). Although the steps, operations, or computations may bepresented in a specific order, this order may be changed in differentembodiments. In some embodiments, to the extent multiple steps are shownas sequential in this specification, some combination of such steps inalternative embodiments may be performed at the same time. The sequenceof operations described herein can be interrupted, suspended, orotherwise controlled by another process, such as an operating system,kernel, etc. The routines can operate in an operating system environmentor as stand-alone routines. Functions, routines, methods, steps andoperations described herein can be performed in hardware, software,firmware or any combination thereof.

Embodiments described herein can be implemented in the form of controllogic in software or hardware or a combination of both. The controllogic may be stored in an information storage medium, such as acomputer-readable medium, as a plurality of instructions adapted todirect an information processing device to perform a set of stepsdisclosed in the various embodiments. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the invention.

It is also within the spirit and scope of the invention to implement insoftware programming or of the steps, operations, methods, routines orportions thereof described herein, where such software programming orcode can be stored in a computer-readable medium and can be operated onby a processor to permit a computer to perform any of the steps,operations, methods, routines or portions thereof described herein. Theinvention may be implemented by using software programming or code inone or more general purpose digital computers, by using applicationspecific integrated circuits, programmable logic devices, fieldprogrammable gate arrays, optical, chemical, biological, quantum ornanoengineered systems, components and mechanisms may be used. Ingeneral, the functions of the invention can be achieved by any means asis known in the art. For example, distributed, or networked systems,components and circuits can be used. In another example, communicationor transfer (or otherwise moving from one place to another) of data maybe wired, wireless, or by any other means.

A “computer-readable medium” may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, system ordevice. The computer readable medium can be, by way of example only butnot by limitation, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, system, device,propagation medium, or computer memory. Such computer-readable mediumshall generally be machine readable and include software programming orcode that can be human readable (e.g., source code) or machine readable(e.g., object code).

A “processor” includes any, hardware system, mechanism or component thatprocesses data, signals or other information. A processor can include asystem with a general-purpose central processing unit, multipleprocessing units, dedicated circuitry for achieving functionality, orother systems. Processing need not be limited to a geographic location,or have temporal limitations. For example, a processor can perform itsfunctions in “real-time,” “offline,” in a “batch mode,” etc. Portions ofprocessing can be performed at different times and at differentlocations, by different (or the same) processing systems.

It will also be appreciated that one or more of the elements depicted inthe drawings/figures can also be implemented in a more separated orintegrated manner, or even removed or rendered as inoperable in certaincases, as is useful in accordance with a particular application.Additionally, any signal arrows in the drawings/figures should beconsidered only as exemplary, and not limiting, unless otherwisespecifically noted.

Furthermore, the term “or” as used herein is generally intended to mean“and/or” unless otherwise indicated. As used herein, including theclaims that follow, a term preceded by “a” or “an” (and “the” whenantecedent basis is “a” or “an”) includes both singular and plural ofsuch term, unless clearly indicated within the claim otherwise (i.e.,that the reference “a” or “an” clearly indicates only the singular oronly the plural). Also, as used in the description herein and throughoutthe claims that follow, the meaning of “in” includes “in” and “on”unless the context clearly dictates otherwise.

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any component(s) thatmay cause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as a critical, required, or essentialfeature or component of any or all the claims.

What is claimed is:
 1. A system for providing tamper protection,comprising: an archive node appliance coupled to a media library and aset of hosts, the archive node appliance comprising a processor, anon-transitory computer readable memory, and computer instructionsexecutable by the processor to cause the archive node appliance to: loada tape cartridge containing a tape in the media library, the tapecartridge having a memory; read a first set of tamper protection datafrom the tape; read a second set of tamper protection data from thememory of the tape cartridge, each of the first set of tamper protectiondata from the tape and the second set of tamper protection data from thememory of the tape cartridge comprising: an index generation valueassociated with modification of the tape; a universally uniqueidentifier (UUID) associated with the tape; verification data generatedusing the index generation value, the UUID, or both; a checksumassociated with a metadata file on the tape; or a combination thereof;and determine whether the tape has been altered by comparing the firstset of tamper protection data from the tape and the second set of tamperprotection data from the memory of the tape cartridge.
 2. The system ofclaim 1, wherein the computer instructions are further executable by theprocessor to cause the archive node appliance to: write tamperprotection data to the tape and to the memory of the tape cartridge whena file stored on the tape is updated.
 3. The system of claim 1, whereinthe first set of tamper protection data and the second set of tamperprotection data are written to the tape and to the memory of the tapecartridge by the archive node appliance or another archive nodeappliance.
 4. The system of claim 1, wherein the verification datacomprises a hash or a checksum generated using the index generationvalue, the UUID, or both.
 5. The system of claim 1, wherein the computerinstructions are further executable by the processor to cause thearchive node appliance to: determine whether the metadata file on thetape has been altered by comparing the checksum in the first set oftamper protection data from the tape and the checksum in the second setof tamper protection data from the memory of the tape cartridge.
 6. Thesystem of claim 1, wherein the computer instructions are furtherexecutable by the processor to cause the archive node appliance to: whenthe metadata file on the tape is updated, update the checksum in thefirst set of tamper protection data on the tape and the checksum in thesecond set of tamper protection data in the memory of the tapecartridge.
 7. The system of claim 1, wherein the computer instructionsare further executable by the processor to cause the archive nodeappliance to: mark the tape as read only when metadata maintained by thearchive node appliance is associated with a first metadata versionnumber that is older than a second metadata version number associatedwith the metadata file on the tape.
 8. A computer program productcomprising at least one non-transitory computer readable medium storinginstructions executable by at least one processor to: load a tapecartridge containing a tape in a media library, the tape cartridgehaving a memory; read a first set of tamper protection data from thetape; read a second set of tamper protection data from the memory of thetape cartridge, each of the first set of tamper protection data from thetape and the second set of tamper protection data from the memory of thetape cartridge comprising: an index generation value associated withmodification of the tape; a universally unique identifier (UUID)associated with the tape; verification data generated using the indexgeneration value, the UUID, or both; a checksum associated with ametadata file on the tape; or a combination thereof; and determinewhether the tape has been altered by comparing the first set of tamperprotection data from the tape and the second set of tamper protectiondata from the memory of the tape cartridge.
 9. The computer programproduct of claim 8, wherein the instructions are further executable bythe at least one processor to: write tamper protection data to the tapeand to the memory of the tape cartridge when a file stored on the tapeis updated.
 10. The computer program product of claim 8, wherein thefirst set of tamper protection data and the second set of tamperprotection data are written to the tape and to the memory of the tapecartridge by an archive node appliance.
 11. The computer program productof claim 8, wherein the verification data comprises a hash or a checksumgenerated using the index generation value, the UUID, or both.
 12. Thecomputer program product of claim 8, wherein the instructions arefurther executable by the at least one processor to: determine whetherthe metadata file on the tape has been altered by comparing the checksumin the first set of tamper protection data from the tape and thechecksum in the second set of tamper protection data from the memory ofthe tape cartridge.
 13. The computer program product of claim 8, whereinthe instructions are further executable by the at least one processorto: when the metadata file on the tape is updated, update the checksumin the first set of tamper protection data on the tape and the checksumin the second set of tamper protection data in the memory of the tapecartridge.
 14. A method for providing tamper protection, comprising:loading, by an archive node appliance having a processor and anon-transitory computer readable memory, a tape cartridge containing atape in a media library coupled to the archive node appliance, the tapecartridge having a memory; the archive node appliance reading a firstset of tamper protection data from the tape; the archive node appliancereading a second set of tamper protection data from the memory of thetape cartridge, each of the first set of tamper protection data from thetape and the second set of tamper protection data from the memory of thetape cartridge comprising: an index generation value associated withmodification of the tape; a universally unique identifier (UUID)associated with the tape; verification data generated using the indexgeneration value, the UUID, or both; a checksum associated with ametadata file on the tape; or a combination thereof; and the archivenode appliance determining whether the tape has been altered bycomparing the first set of tamper protection data from the tape and thesecond set of tamper protection data from the memory of the tapecartridge.
 15. The method according to claim 14, further comprising: thearchive node appliance writing tamper protection data to the tape and tothe memory of the tape cartridge when a file stored on the tape isupdated.
 16. The method according to claim 14, wherein the first set oftamper protection data and the second set of tamper protection data arewritten to the tape and to the memory of the tape cartridge by thearchive node appliance or another archive node appliance.
 17. The methodaccording to claim 14, wherein the verification data comprises a hash ora checksum generated using the index generation value, the UUID, orboth.
 18. The method according to claim 14, further comprising: thearchive node appliance determining whether the metadata file on the tapehas been altered by comparing the checksum in the first set of tamperprotection data from the tape and the checksum in the second set oftamper protection data from the memory of the tape cartridge.
 19. Themethod according to claim 14, further comprising: when the metadata fileon the tape is updated, the archive node appliance updating the checksumin the first set of tamper protection data on the tape and the checksumin the second set of tamper protection data in the memory of the tapecartridge.
 20. The method according to claim 14, further comprising: thearchive node appliance marking the tape as read only when metadatamaintained by the archive node appliance is associated with a firstmetadata version number that is older than a second metadata versionnumber associated with the metadata file on the tape.